Protocol timers are often used, e.g., in re-transmission protocols, so that a new message or action is repeated in case a desired outcome has not taken place before the timer has expired. This is the case, for example, in the Radio Link Control (RLC) protocol in the UMTS Terrestrial Radio Access Network (UTRAN), where various timers such as, e.g., the Poll Timer is defined. The purpose of this timer is to re-transmit a Poll after the expiry of the timer to cover the situation if the Poll (or the peer's Status report) has been lost over an error-prone link. Note that similar timers are used in almost all protocols striving for reliability, including signaling (layer 3) protocols.
The Enhanced Dedicated Channel (E-DCH) is an uplink transport channel defined in the Third Generation Partnership Project (3GPP) Rel 6. One new feature of E-DCH is the introduction of Hybrid Automatic Repeat Request (HARQ). HARQ is also used in High Speed Downlink Shared Channel (HS-DSCH), and it is planned for the Long Term Evolution (LTE) of UTRAN.
In the E-DCH protocol stack, shown in FIG. 2, there are then two layers of retransmissions. The first retransmitting entity is the HARQ protocol on the Medium Access Control (MAC) layer, which performs retransmissions based on a one bit acknowledgement/negative acknowledgement (ACK/NACK). If HARQ fails, or a NACK to ACK error occurs, out-of-sequence delivery is performed to the next retransmitting entity, which is the RLC automatic repeat request (ARQ) protocol. RLC then cares for the residual errors.
RLC is present at both ends of the connection; in the user equipment (UE) and in the radio network controller (RNC). Retransmissions are made based on STATUS reports, which on the other hand are performed based on timers and polling. In other words, RLC retransmissions can be controlled with RLC parameters including timer values and polling rules.
RLC was already present in the previous 3GPP releases, where no HARQ protocol was used, i.e. with Dedicated Control Channel (DCH) and Forward Access Channel/Random Access Channel (FACH/RACH). Most RLC timer values are therefore typically based on an estimate of the Round-Trip-Time (RTT) on the RLC layer. With HARQ in place, however, the calculation of RTT on the RLC layer becomes tricky. This is because the delay may vary substantially due to the HARQ, since a payload unit in a HARQ process can be subject to varying number of re-transmissions. The present specifications consider that the RTT can vary (mainly for RACH) but do not include suitable inter-layer communication for supporting the varying HARQ delay for E-DCH.
With HARQ in operation, a correct setting of the timers in upper-layer protocols is far from trivial. This is exemplified with an E-DCH having 10 ms Transmission Time Interval (TTI) with four HARQ processes. Suppose the number of HARQ re-transmissions vary between 1 and 8. Depending on the HARQ operation, the transmission delay can then vary between 10 ms and [7×40+10] ms=290 ms.
The RLC specification (TS 25.322) defines the start of many of its timers as follows:                “In the UE this timer shall be started (or restarted) when the successful or unsuccessful transmission of an AMD PDU containing a poll is indicated by lower layer”        
Indeed, the MAC layer is specified to send an indication to RLC, when the RLC Protocol Data Units (PDU) has been submitted for transmission by the physical layer:                MAC-STATUS-Ind/Resp:        [ . . . ] At the UE, MAC-STATUS-Ind primitive is also used to indicate from MAC to RLC that MAC has requested data transmission by PHY (i.e. PHY-DATA-REQ has been submitted), or that transmission of an RLC PDU on RACH has failed due to exceeded preamble ramping cycle counter.        
And further (the parameter indicating the status of the transmission):                TX status:                    when set to value “transmission unsuccessful” this parameter indicates to RLC that transmission of an RLC PDU failed in the previous TTI, when set to value “transmission successful” this parameter indicates to RLC that the requested RLC PDU(s) has been submitted for transmission by the physical layer.                        
Thus, MAC is obligated to inform the RLC when the transmission of a PDU has commenced by the physical layer. However, there is no indication of the successful/unsuccessful reception of the PDU at the peer entity. In particular, there is no definition of how to use the indication when the RLC PDUs are carried over E-DCH with HARQ. Thus, the MAC specification is unclear in this respect.
As observed through the example above, the delay from the data request until a successful transmission with HARQ has been performed can vary significantly. Thus, in order to deal with this delay-variation, there is a need to update the specification such that the HARQ delay-variations can be catered for by the upper layers—particularly by RLC timers.